ビデオコーディングのための効率的な変換技術

专利摘要:
本開示は、ビデオコーディングにおいて使用されることができる効率的な変換技術を記述する。特に、ビデオデータの第１のブロックの変換に関係する計算の中間結果を、ビデオデータの第２のブロックの変換に関係する計算の中間結果を計算するときに再使用する。サーチ空間のビデオブロックが変換される動き推定プロセスの間に、効率的な変換技術を使用してもよいが、本開示は、必ずしもこの観点に制限されていない。パイプライン化技術を使用して、効率的な変換技術を加速させてもよく、転置メモリを実現して、効率的なパイプライン化を容易にしてもよい。
公开号:JP2011509538A
申请号:JP2010527212
申请日:2008-09-26
公开日:2011-03-24
发明作者:シュ、デ・デゾ；ナガラジ、ラグハベンドラ・シー．；モロイ、スティーブン
申请人:クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ；
IPC主号:H04N7-30

专利说明:

[0001] 本発明は、デジタルビデオ処理に関連し、より詳細には、ビデオデータのブロックベースのコーディングに関連する。]
関連技術の説明

[0002] ビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレス通信デバイス、パーソナルデジタルアシスタント（ＰＤＡ）、ラップトップコンピュータ、デスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、セルラまたは衛星無線電話機、ビデオゲーム協議、ハンドヘルドゲームデバイス、および類似物を含む、幅広いデバイスに組み込むことができる。デジタルビデオコーディングは、フルモーションマルチメディアシーケンスを、作成し、修正し、送信し、記憶し、記録し、および、再生する際に、従来のアナログシステムに比して、かなりの改善をもたらすことができる。ブロードキャストネットワークは、ビデオコーディングを使用して、１つ以上のチャネルのマルチメディア（オーディオ−ビデオ）シーケンスのワイヤレス加入者デバイスに対するブロードキャストを容易にしてもよい。ビデオコーディングをまた使用して、セルラ無線電話によるビデオ会議のような、ビデオテレフォニー（ＶＴ）アプリケーションをサポートしてもよい。]
[0003] デジタルビデオシーケンスをコーディングするために、多数の異なるコーディング標準規格が確立されている。例えば、動画像符号化専門家会合（ＭＰＥＧ）は、ＭＰＥＧ−１、ＭＰＥＧ−２、およびＭＰＥＧ４を含む多数の標準規格を開発してきた。他の標準規格は、国際電気通信連合（ＩＴＵ）Ｈ．２６３標準規格、Ｈ．２６４標準規格、カリフォルニア州キューパーティーノのアップルコンピュータ社（登録商標）によって開発されたクイックタイム（登録商標）技術、ワシントン州レッドモンドのマイクロソフトコーポレーション（登録商標）により開発されたウィンドウズ（登録商標）用ビデオ、インテルコーポレーション（登録商標）によって開発されたｉｎｄｅｏ（登録商標）、ワシントン州シアトルのリアルネットワークス社（登録商標）からのリアルビデオ（登録商標）、スーパーマック社によって開発されたシネパック（登録商標）等を含む。さらに、新しい標準規格が、出現および進化し続けている。ＩＴＵ Ｈ．２６４はまた、ＭＰＥＧ−４、パート１０、アドバンストビデオコーディング（ＡＶＣ）においても記述されている。]
[0004] ほとんどのビデオコーディング技術は、ブロックベースのコーディングを利用しており、これは、ビデオフレームをピクセルのブロックへと分割し、ピクセルブロックを、ビデオシーケンス中の、他のフレームのピクセルブロックに相関させる。現在のブロックと、別のフレームの予測ブロックとの間の差分をエンコーディングすることによって、データ圧縮が達成できる。用語“マクロブロック”を使用して、（典型的に、ビデオシーケンスの前のまたは後続のフレームのサブセットである）サーチ空間に対して比較されたビデオフレームのディスクリートブロックを規定することが多い。マクロブロックはまた、パーティション、または、サブパーティションへとさらにサブ分割されてもよい。ＩＴＵＨ．２６４標準規格は、１６×１６マクロブロック、１６×８パーティション、８×１６パーティション、８×８パーティション、８×４サブパーティション、４×８サブパーティション、４×４サブパーティションをサポートする。他の標準規格は、異なるサイズのブロック、マクロブロック、パーティション、および／または、サブパーティションをサポートしてもよい。]
[0005] ビデオフレーム中のそれぞれのブロック（マクロブロック、パーティション、または、サブパーティション）に対して、エンコーダは、１つ以上の直前のビデオフレーム（および／または、後続のフレーム）の類似サイズのブロックを比較して、“予測ブロック”または“ベストマッチ”として呼ばれる、類似のブロックを識別する。現在のビデオブロックを、他のフレームのビデオブロックに比較するプロセスは、一般的に、動き推定として呼ばれる。いったん、コードされることになる所定のブロックに対する“ベストマッチ”が識別されると、エンコーダは、現在のブロックと、ベストマッチとの間の差分をエンコードできる。現在のブロックと、ベストマッチとの間の差分をエンコーディングするこのプロセスは、動き補償として呼ばれるプロセスを含む。動き補償は、（残余として呼ばれる）差分ブロックを作成することを含み、これは、エンコードされることになる現在のブロックと、ベストマッチとの間の差分を示す情報を含む。特に、動き補償は、通常は、動きベクトルを使用して、ベストマッチをフェッチして、次に、入力ブロックからベストマッチを抽出して、残余を発生させる動作を指す。エントロピーコーディングのような追加のコーディングステップを、残余上で実行して、ビットストリームをさらに圧縮してもよい。]
概要

[0006] 本開示は、ビデオコーディングにおいて使用されることができる効率的な変換技術を記述する。特に、ビデオデータの第１のブロックの変換に関係する計算の中間結果を、ビデオデータの第２のブロックの変換に関係する計算の中間結果を計算するときに再使用する。サーチ空間のビデオブロックが変換される動き推定プロセスの間に、効率的な変換技術を使用してもよいが、本開示は、必ずしもこの観点に制限されていない。本開示にしたがうと、サーチ空間は、異なる４×４ピクセルブロックへと分けられてもよく、この異なる４×４ピクセルブロックは、互いにオーバーラップしていてもよい。]
[0007] ４×４ピクセルブロックの行に１次元変換を実行して、中間結果を発生させてもよく、次に、中間結果の列に１次元変換を実行してもよい。代わりに、最初に、列に１次元変換を実行して、次に、中間結果の行に１次元変換を実行してもよい。何れのケースにおいても、サーチ空間内の異なる４×４ピクセルブロックの間にオーバーラップがあるとすると、同一の計算を実行することなく、中間結果の少なくともいくつかのものを再使用（例えば、後の変換とともに共有）することができる。ここで記述する技術の実現のための効率的なアーキテクチャもまた開示する。]
[0008] １つの例において、本開示は、ビデオデータのブロック上で変換を実行することを含む方法を提供し、変換を実行することは、ビデオデータの第１のブロックの第１の変換に関係する１つ以上の計算を、ビデオデータの第２のブロックの第２の変換において再使用することを含む。]
[0009] 別の例において、本開示は、ビデオデータのブロック上で変換を実行するビデオコーダを具備するデバイスを提供する。変換を実行する際に、ビデオコーダは、ビデオデータの第１のブロックの第１の変換に関係する１つ以上の計算を、ビデオデータの第２のブロックの第２の変換において再使用する。]
[0010] 別の例において、本開示は、ビデオデータのブロック上で変換を実行する手段と、ビデオデータの第１のブロックの第１の変換に関係する１つ以上の計算を、ビデオデータの第２のブロックの第２の変換において再使用する手段とを具備するデバイスを提供する。]
[0011] ここで記述する技術は、ハードウェア、ソフトウェア、ファームウェア、または、これらの任意の組み合わせで実現されてもよい。ソフトウェアで実現される場合、ソフトウェアは、デジタル信号プロセッサ（ＤＳＰ）、または、他のタイプのプロセッサもしくはデバイスにおいて実行されてもよい。技術を実行するソフトウェアは、コンピュータ読取可能媒体中に最初に記憶されていてもよく、プロセッサ、もしくは他のデバイス中にロードされ、実行されて、ここで記述する技術を使用したビデオコーディングを可能にしてもよい。]
[0012] したがって、本開示はまた、命令を備えるコンピュータ読取可能媒体も企図しており、命令は、ビデオコーディングデバイス中で実行されるときに、デバイスに、ビデオデータのブロック上で変換を実行させ、変換を実行させる際に、命令は、デバイスに、ビデオデータの第１のブロックの第１の変換に関係する１つ以上の計算を、ビデオデータの第２のブロックの第２の変換において再使用させる。]
[0013] さらに、本開示は、ビデオデータのブロック上で変換を実行するように構成されている回路も企図しており、変換を実行する際に、回路は、ビデオデータの第１のブロックの第１の変換に関係する１つ以上の計算を、ビデオデータの第２のブロックの第２の変換において再使用する。]
[0014] 追加的に、以下でより詳細に記述するように、パイプライン化技術を使用して、効率的な変換技術を加速させてもよく、転置メモリを実現して、効率的なパイプライン化を容易にしてもよい。さまざまな実施形態のさらなる詳細を、添付の図面と、以下の説明において述べる。他の特徴、目的、および利点が、詳細な説明と図面から、また、特許請求の範囲から明らかになるだろう。]
図面の簡単な説明

[0015] 図１は、本開示の技術を実現するビデオコーディングデバイスの例示的なビデオコーダを図示するブロック図である。
図２は、変換を含む、動き推定処理の一部を実現するコンポーネントを図示するブロック図である。
図３は、変換を含む、動き推定処理の一部を実現するコンポーネントを図示するブロック図である。
図４は、１次元変換を実行するためのバタフライ実現を図示する図である。
図５は、ここで記述するような変換に対して、計算共有技術を使用するアーキテクチャを図示するブロック図である。
図６は、本開示にしたがって、達成される計算的な節約を図示するグラフである。
図７は、並列でサーチされるサーチポイントの数の関数としての変換エンジンの数を図示するグラフである。
図８は、例示的な垂直型エンジンを図示するブロック図である。
図９は、サーチ空間の最初の４×４ピクセルブロックを変換するのに使用されてもよい例示的な水平型エンジンを図示するブロック図である。
図１０は、図８に示した水平型エンジンによって実行された変換に続いて、サーチ空間の残りの４×４ピクセルブロックを変換するのに使用されてもよい例示的な水平型エンジンを図示するブロック図である。
図１１は、垂直型エンジンへの入力ブロックを図示するサーチ空間内のブロックの概念図である。
図１２は、水平型エンジンと、垂直型エンジンとの間のデータフローを図示する図である。
図１３は、水平型エンジンと、垂直型エンジンとの間に存在する転置レジスタ中のタイミングとデータフローを図示するブロック図である。] 図１ 図１０ 図１１ 図１２ 図１３ 図２ 図３ 図４ 図５ 図６
発明の実施形態の詳細な説明

[0016] 本開示は、ビデオコーディングにおいて有用である効率的な変換技術を記述する。以下でより詳細に説明することになるように、ビデオデータの第１のブロックの変換に関係する計算の中間結果を、ビデオデータの第２のブロックの変換において再使用する。サーチ空間のビデオブロックが変換される動き推定プロセスの間に実行される、整数変換、または、フォワード離散コサイン変換に対して、この技術は特に有用である。しかしながら、ビデオコーディングに関係する、他の変換の文脈においてこの技術を使用してもよい。実際、任意のタイプの線形変換、整数変換、および、潜在的に、他の変換の文脈において、この技術は有用であってもよい。]
[0017] 本開示にしたがうと、（任意のサイズの）サーチ空間は、４×４ピクセルブロックのような、異なるビデオブロックへと分けられてもよい。サーチ空間内で規定される４×４ピクセルブロックは、互いにオーバーラップしていてもよい。例として、５×５ピクセルサーチ空間は、４つの異なる４×４ピクセルブロックを規定してもよいが、分数分解能に対する内挿を使用して、５×５ピクセルサーチ空間内で、さらに多くの４×４ピクセルブロックを規定することができる。４×４ピクセルブロックを、ピクセルドメインから、空間周波数ドメインへと変換するときに、サーチ空間を使用してもよい。１つのドメインから別のものに対する、この変換の間に、典型的に２つの１次元変換パスが、４×４ピクセルブロック上で実行される。列上で第１のパスを実行して、（中間結果として呼ばれる）水平空間周波数コンポーネントを発生させ、１行以上の行上で第２のパスを実行して、垂直空間周波数コンポーネントを発生させる。当業者は、行上で第１のパスを実行してもよく、列上で第２のパスを実行してもよいことを、全く困難なく理解することになるだろう。]
[0018] ４×４ピクセルブロックの列に１次元変換を実行して中間結果を発生させ、次に、中間結果の行に１次元変換を実行してもよい。サーチ空間中の異なる４×４ピクセルブロックの間にオーバーラップがあるとすると、同一の計算を実行することなく、中間結果の少なくともいくつかのものを再使用することができる。このような方法で、計算を避けて効率性を高めることができる。ここで記述する技術の効率的な実現を達成することができる、例示的なハードウェアアーキテクチャも開示する。このケースでは、パイプライン技術を使用して、ビデオデータの１組のブロックの効率的な変換技術を加速させてもよく、転置メモリを実現して、効率的なパイプライン化を容易にしてもよい。]
[0019] 図１は、本開示の技術を実現してもよいビデオコーディングデバイスの例示的なビデオコーダ１０を図示するブロック図である。実際、幅広いさまざまなデバイスが、本開示の教示から利することができるビデオコーダを実現してもよい。例として、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレス通信デバイス（例えば、ハンドセット）、パーソナルデジタルアシスタント（ＰＤＡ）、ラップトップコンピュータ、デスクトップコンピュータ、デジタルカメラ、デジタルレコーディングデバイス、セルラもしくは衛星無線電話機、ビデオゲーム協議、ハンドヘルドゲームデバイス、および類似物において、ビデオコーダ１０を使用してもよい。ブロードキャストネットワークは、ビデオコーディングを使用して、１つ以上のチャネルのマルチメディア（オーディオ−ビデオ）シーケンスのワイヤレス加入者デバイスに対するブロードキャストを容易にしてもよい。また、ビデオコーディングを使用して、セルラ無線電話機によるビデオ会議、とともに、他のさまざまなアプリケーションのような、ビデオテレフォニー（ＶＴ）アプリケーションをサポートしてもよい。] 図１
[0020] 図１に示したように、ビデオコーダ１０は、入力マクロブロック（ＭＢ）を受け取る。用語“マクロブロック”を使用して、サーチ空間に対して比較されて、コード化されるビデオフレームの離散ブロックを規定することが多い。マクロブロックはまた、パーティション、または、サブパーティションへとさらにサブ分割されてもよい。ＩＴＵＨ．２６４標準規格は、１６×１６マクロブロック、１６×８パーティション、８×１６パーティション、８×８パーティション、８×４サブパーティション、４×８サブパーティション、４×４サブパーティションをサポートする。他の標準規格は、異なるサイズのブロック、マクロブロック、パーティション、および／または、サブパーティションをサポートしてもよい。いずれのケースにおいても、用語“マクロブロック”を使用して、本開示の観点を記述してもよく、ここで記述する技術は、マクロブロック、パーティション、サブパーティション、または、他のビデオブロックサイズを含む、ビデオデータの任意のサイズのブロックをコーディングする際に有用である。] 図１
[0021] 図１に示したように、それぞれの入力ＭＢに対して、（図１において“予測”としてラベル付けされている）予測ブロックを発生させる。予測ブロックを、ベストマッチとして呼ぶこともある。ユニット１２によって、入力ＭＢから予測ブロックを減じて、（図１において“ＲＥＳ”としてラベル付けされている）残余を発生させる。残余は、入力ＭＢと、入力ＭＢをコードするのに使用される予測ブロックとの間の差分を示すデータのブロックを含む。動きベクトル（または、イントラコーディングに対しては、イントラベクトル）によって、予測ブロックを識別してもよい。イントラコーディングに対して、予測ブロックは、入力ＭＢと同じフレーム内に位置している。インターコーディングに対して、予測ブロックは、入力ＭＢと異なるフレーム内に位置している。動きベクトル（または、イントラコーディングに対しては、イントラベクトル）は、コーディングにおいて使用される予測ブロックを識別する。インターコーディングは、予測的（Ｐ）なものであることができ、このことは、予測ブロックが、ビデオシーケンスの前のフレームに基づいていることを意味し、あるいは、インターコーディングは、２方向（Ｂ）であることができ、このことは、予測ブロックが、ビデオシーケンスの前のフレーム、または、後続するフレームに基づいていることを意味する。] 図１
[0022] 残余（Ｒｅｓ）を作成する際に、残余に変換と量子化が実行される。変換ユニット１４と、量子化ユニット１６が、それぞれ、変換と量子化を実行する。また、エントロピーコーディングを実行して、出力ビットストリームを発生させてもよい。エントロピーコーディングユニット１８は、エントロピーコーディングを実行し、このことは、さらなる圧縮を達成してもよい。エントロピーコーディングは、１組のビットに対してコードを割り当てることと、コード長を、確率にマッチングさせることとを含んでもよい。さまざまなエントロピーコーディングはビデオシステムコーディングにおいてよく知られており、共通している。]
[0023] ビデオコーダ１０の予測ループにおいて、逆量子化ユニット２２と、逆変換ユニット２４とが、残余に逆量子化と逆変換とを実行して、ユニット１２と１４によって実行された変換と量子化を本質的に反転させる。加算器ユニット２６によって、予測ブロックが、再構成された残余に追加し戻される。これは、予測ループにおいて、入力ＭＢを本質的に再作成する。再構成されたＭＢのエッジは、デブロッキングユニット２８によってフィルタされ、メモリ３０に記憶されてもよい。]
[0024] 量子化は、原則として、変換された信号のダイナミックレンジを減少させることを含む。ダイナミックレンジを減少させることは、エントロピーコーディングによって発生されるビット（レート）数に影響を及ぼす。このことはまた、残余中の損失をもたらし、これは、オリジナルのＭＢと、再構成されたＭＢが、わずかに異なることをもたらしかねない。これらの差分は、通常は、量子化エラーまたは歪みとして呼ばれる。量子化の強度は、量子化パラメータによって決定される。より大きい量子化パラメータは、より高い歪みをもたらすが、コーディングレートを下げることができる。]
[0025] 予測ループは、イントラ予測ループ、または、インター予測ループであってもよい。ＭＰＥＧ−４、およびＩＴＵＨ．２６３は、典型的に、インター予測だけをサポートする。ＩＴＵ Ｈ．２６４は、イントラ、およびインター予測の両方をサポートする。図１のビデオコーダ１０において、制御信号３２は、ループが、イントラ予測、または、インター予測であるかどうかを選択してもよい。しかしながら、本開示の技術は、イントラコーディング、または、インターコーディングだけをサポートするシステムにおいても作用することができる。] 図１
[0026] イントラ予測において、ユニット３４は、空間的推定と、空間的補償を実行する。このケースでは、ユニット３４は、再構成されたＭＢを、同じビデオフレーム内の隣接マクロブロックに対して比較して、イントラ予測値（predictor）ブロックを発生させる。イントラ予測値ブロックは、本質的に、再構成されたＭＢに対するベストマッチであり、これは、残余中の良好な圧縮をもたらすだろう。イントラ予測は、空間的冗長性を減少させるのを支援することができる。]
[0027] インター予測において、ユニット３６は、動き推定と動き補償を実行する。動き推定は、再構成されたＭＢを、前の、または、将来のフレームのブロックに対して比較して、インター予測値を発生させる。インター予測値は、再構成されたＭＢに対するベストマッチであるが、イントラ予測値とは異なって、インター予測値は、異なるビデオフレームからもたらされたものである。インター予測は、時間的冗長性を減少させるのを支援することができる。典型的に、時間的冗長性の活用は、空間的冗長性の活用よりも、ビデオシーケンスの圧縮において、より大きいインパクトを持つことができる。換言すれば、ＭＢのインターコーディングは、通常、イントラコーディングより良好な圧縮を達成する。]
[0028] 本開示の技術は、一般的に、フォワード離散コサイン変換のような変換に関係する。モーション推定プロセスの間に技術を実現してもよいが、本開示はこの観点に制限されているわけではない。説明の目的で、本開示は、動き推定の間に実行されるとして技術を説明することになるが、これらの技術、または、類似の技術を、変換が実行される、他の文脈において使用してもよい。]
[0029] 動き推定は、ビデオコーダによって実行されることができる計算集約的なプロセスである。多数の計算は、動き推定において考慮される可能性のある多数の潜在的な予測値によるものであるかもしれない。実際に、動き推定は、通常は、１つ以上の前のフレーム（または、後続するフレーム）のサブセットを含むサーチ空間中で、インター予測値をサーチすることを含む。サーチ空間からの候補は、コスト関数またはメトリックのベースで調べられてもよく、これは、通常は、絶対差分の合計（ＳＡＤ）、２乗差分の合計（ＳＳＤ）、絶対変換差分の合計（ＳＡＴＤ）、または、２乗変換差分の合計（ＳＳＴＤ）のような異なる計算を実行することによって規定される。いったん、サーチ空間中のすべての候補に対してメトリックが計算されると、メトリックを最小化させる候補が、インター予測値として選ばれることができる。したがって、動き推定に影響を及ぼす主要な要因は、サーチ空間のサイズ、サーチ方法、および、さまざまなコスト関数であってもよい。コスト関数は、本質的に、現在のフレームのオリジナルブロックと、サーチエリアの候補ブロックとの間の冗長性を定量化する。冗長性は、正確なレートと歪みに関して定量化されてもよい。]
[0030] 図２は、変換ベースのメトリックフレームワークを示す。図２に示したブロックは、（図１に示したユニット３６のような）動き推定器によって実行される機能を含んでもよい。図２において、例示的なビット長を図示したが、本開示の技術は、何らかの特定のビット長に制限されていない。再び、動き推定は、エンコードされることになるブロックを、サーチ空間内の複数の候補に対して比較して、エンコードされることになるブロックにベストマッチする、サーチ空間内の１つのブロックを見つけることを含む。本開示にしたがうと、ベストマッチは、レートと、歪みという点で規定されてもよい。] 図１ 図２
[0031] 動き推定を達成するために、エンコードされることになるブロックと、所定のサーチ空間ブロックとの間で、残余エネルギーが分析される。各サーチ空間ブロックのピクセルから、エンコードされることになるブロックの対応するピクセルを減ずるプロセスを通して、それぞれの残余候補が取得される。これは、図２の差分（Ｄｉｆｆ）モジュール４２が、例えば、ＳＡＤ、ＳＳＤ、ＳＡＴＤ、または、ＳＳＴＤ技術によって、達成していることである。残余ブロックは、次に、フォワード変換エンジン（ＦＴＥ）４４を使用して、周波数ドメインへと変換され、ＦＴＥ４４は、フォワード離散コサイン変換を実行してもよい。変換された残余ブロックは、そのレートおよび歪みプロパティに対して分析されることができる。特に、レート歪み推定（ＲＤＥ）モジュール４６が、本質的に、所定の量子化パラメータＱＰにおいて、この所定のサーチ空間ブロックに対する結果となる、レート（Ｒ）および歪み（Ｄ）を推定する。ＲＤＥモジュール４６は、次に、ラグランジュ原則に基づいて、ＲとＤを単一のコストメトリック（＝Ｄ＋λＲ）へと結合させ、これは、メトリックが少なくとも部分的にＲとＤに依拠する範囲において、レート歪みメトリックとして呼ばれてもよい。すべての候補サーチ空間ブロックに対するコストが比較されてもよく、いずれかのものが、コーディングに対する最小コストが選ばれることをもたらす。] 図２
[0032] 上で計算されたコストメトリックは、４×４ピクセルのサイズであるサーチ空間ブロックと、コード化されているブロックとに対応することに留意すべきである。４×４ピクセルより大きいブロックサイズに対しては、複数の４×４ピクセルブロックを使用して、より大きいブロックを覆ってもよい。このケースでは、より大きいブロックを覆う、すべての４×４ユニットブロックに対して、コストメトリックを累積することによって、より大きいブロックに対するコストを計算してもよい。以下の記述は、４×４ピクセルのブロックサイズに焦点を当てるが、技術は、他のサイズのブロックを適用できる。]
[0033] フォワード変換エンジン（ＦＴＥ）４４は、一般的に、任意の変換ベースのメトリック計算の基本的モジュールである。変換の線形的性質によって、差分モジュール４２とＦＴＥ４４との段階を交換することができる。本開示にしたがうと、差分モジュール４２と、ＦＴＥ４４との順序を交換することは、変換の間の計算上の節約を可能にすることができる。示したブロックの入力および出力の表記は、入力の（列）×（行）×（値を表すのに使用されるビット数）である。]
[0034] 図３は、図２に対する代替を示し、ここで、差分モジュール４２とＦＴＥ４４の順序は交換されている。図３のコンポーネントは、動き推定ユニットの一部を形成する。例示的な目的で、ビット長を図示したが、他のビット長も使用できる。図３において、２つの異なるＦＴＥ５２Ａと５２Ｂが、例えば、整数変換またはフォワード離散コサイン変換によって、エンコードされることになるブロック（“エンコードブロック”）と、考慮されているサーチ空間ブロックとを変換する。このケースでは、差分計算は、変換後に差分ユニット５４によって実行される。ＲＤＥモジュール５６は、次に、所定の量子化パラメータＱＰにおいて、この所定のサーチ空間ブロックに対する結果となるレート（Ｒ）と、歪み（Ｄ）とを推定する。ＲＤＥモジュール５６は、次に、ラグランジュ原則に基づいて、ＲとＤを単一のコスト（＝Ｄ＋λＲ）へと結合させる。次に、動き推定ユニット（例えば、図１のユニット３６）において、すべての候補サーチ空間ブロックに対するコストが比較されてもよく、いずれかの候補が、コーディングに対する最小コストが選ばれることをもたらす。] 図１ 図２ 図３
[0035] 動き推定の基本的問題は、サーチ空間（ｓ）から、エンコードされることになるブロック（エンコードブロック、ｅ）に対する“ベストマッチ”を見つけることである。エンコードブロック（ｅ）とサーチ空間（ｓ）は、以下のように規定されてもよい。]
[0036] 理解されることができるように、ｅは、ｓにおける４つのサーチポイントに対してマッチされてもよく、これは、以下のように示されることができる。]
[0037] （サーチ）ポイント、例えば、ｓ（０，０）、ｓ（０，１）、ｓ（１，０）、または、ｓ（１，１）は、等しい水平および垂直の次元のブロックとして示したことに留意せよ。ｓ（０，０）は、ブロック００として呼ばれてもよく、ｓ（０，１）は、ブロック０１として呼ばれてもよく、ｓ（１，０）は、ブロック１０として呼ばれてもよく、そして、ｓ（１，１）は、ブロック１１として呼ばれてもよい。サーチポイントはまた、等しくない水平および垂直の次元のブロックも示してもよい。図１１は、いくつかの規定されたサーチポイントを備える８×８サーチエリアを示し、この例に一貫した図解的な目的でブロックを示した。ｓにおいて、ｅに対するベストマッチを見つけるために、残余ブロックｒ（ｘ，ｙ）は、以下のように計算される。] 図１１
[0038] 次に、残余ブロックｒ（ｘ，ｙ）は、変換行列]
[0039] によって、空間的周波数ドメインへと変換される。]
[0040] 等式８において、変数ｖは、垂直列を表し、等式９において、変数ｈは、水平行を表す。変換行列は、整数を包含しており、いくつかの文脈において、これは整数変換として知られており、別の文脈において、これは離散コサイン変換として呼ばれる。離散コサイン変換（ＤＣＴ）は、整数変換、または、“実数”変換のいずれかであってもよい。当業者は、整数または実数によって、変換行列が形成されてもよいことを理解するだろう。４ポイント１次元（１−Ｄ）変換を用いて、ビデオブロックの空間的周波数ドメインコンポーネントを発生させてもよいことに留意すべきである。４ポイント１−Ｄ変換は、最初に、すべての列に適用されて、第１パス中間結果を発生させてもよく、次に、４ポイント１Ｄ変換は、第２のパスにおいて、すべての行の中間結果に適用されてもよい。１−Ｄ変換の“バタフライ実現”を図４に示し、これは、１組の加算器を使用して、入力を異なる方法で結合させて、異なる出力を発生させる。ブリュットフォース（brute force）方法は、Ｒ（０，０）、Ｒ（０，１）、Ｒ（１，０）、または、Ｒ（１，１）の計算に対して、８つの個別の１−Ｄ変換を使用するだろう。ブリュットフォース方法において、それぞれのサーチポイントは、独立して取り扱われ、中間結果Ｒ’（０，０）、Ｒ’（０，１）、Ｒ’（１，０）、または、Ｒ’（１，１）の再使用はない。高精細度テレビジョン（ＨＤＴＶ）に対して、全体のフレームをサーチするのに、１つだけの垂直型、および、１つだけの水平型エンジンが使用される場合、ビデオフレームのリアルタイム提示を容易にするのに、スループットはあまりにも遅すぎる。したがって、以下により詳細に説明するように、ＨＤＴＶまたは他の適応において、サーチをスピードアップさせるために、複数の垂直型および水平型エンジンを並列に使用することができる。] 図４
[0041] 図４に示したように、１つの１−Ｄの４入力変換は、いくつかのステージを持っているとして見られてもよい。変数ｘ0、ｘ1、ｘ2、および、ｘ3は、変換に対する入力を表し、ｙ0、ｙ1、ｙ2、および、ｙ3は、変換の４つの変換された出力を表す。値“ａ”と“ｃ”は、乗法の定数である。したがって、上に“ｃ”を有する矢印は、その矢印の出力が、“ｃ”の値での、入力値（矢印の左側）の乗算の結果であることを意味する。値“ｐ”は、ワード長、すなわち、さまざまなステージに入力されるビット数を表す。] 図４
[0042] 図３に示されるような、修正されたフレームワークが使用される場合、変換の中間結果が再使用されてもよい。特に、等式（７）、（８）、および（９）とは対照的に、２次元変換されたＲ（ｘ，ｙ）は、以下のように取得されることができる。] 図３
[0043] したがって、変換は、ｒ（ｘ，ｙ）の変換から、ｓ（ｘ，ｙ）の変換へと変更されることができる。このことは、ｓ（０，０）（等式３）と、ｓ（０，１）（等式４）との列オーバーラップをなくすことを可能にし、ｓ（１，０）（等式５）と、ｓ（１，１）（等式６）との列オーバーラップをなくすことを可能にする。Ｓ’（０，０）の第１パス中間結果（すなわち、列に関係する結果）を再使用して、Ｓ’（０，１）の第１パス中間結果（すなわち、列に関係する結果）の重複計算を避けてもよい。同様に、Ｓ’（１，０）の第１のパス中間結果（すなわち、列に関係する結果）を再使用して、Ｓ’（１，１）の第１パス中間結果（すなわち、列に関係する結果）の重複計算を避けてもよい。中間結果の（共有とも呼ばれる）この再使用を、以下により詳細に説明する。]
[0044] 再使用（例えば、共有）の概念を図解するために、例として、２次元変換されたｓ（０，０）が、以下のように計算されてもよいことを考慮せよ。]
[0045] さらに、Ｓ（０，１）は、以下のように計算されてもよい。]
[0046] 等式（３）、（４）から以下のことに留意すべきである。]
[0047] したがって、以下の等式のようになる。]
[0048] これは、ｎ∈１，２，３に対して、Ｓ’（０，０）に関係する第１パス中間結果を再使用して、Ｓ’（０，１）に関係する第１パス中間結果を計算してもよい。再使用は、そうでなければ、Ｓ’（０，１）の計算に必要とされてもよい、８つの１−Ｄ変換列変換のうちの３つをなくしてもよいことに留意すべきである。したがって、１−Ｄ変換の最大３７．５％までの節約が、第１パスの間に達成されてもよい。ｓ（０，０）の行を、ｓ（１，０）の行とオーバーラップさせることによって、ビデオブロックもまた処理されてもよいことに注目すべきであり、このケースにおいて、第１パスからもたらされる列への１−Ｄ列変換の第２パスの前に、１−Ｄ行変換が、第１パスの行に適用されるだろう。言い換えると、水平型変換および垂直型変換の順序に関わらず、本開示の技術を適用することができる。]
[0049] 一般的に、Ｎ×Ｍサーチ空間における４×４ブロックのベストマッチをサーチするために、合計（Ｎ−３）×（Ｍ−３）サーチポイントがある。ここでＮは、水平方向での合計ピクセルカウントを表し、Ｍは、垂直方向での合計ピクセルカウントを表す。リアルタイムビデオコーディングのための時間内に、ベストマッチをサーチするタスクを確実に終了させることができるように、複数の１Ｄエンジンを設計することができ、これらを同時に実行できる。“ｊ＋１”（０≦ｊ≦Ｎ−３）ユニットの水平型エンジンを並列に使用して、サーチを加速させて、垂直型変換されたデータが並列で使用されることを仮定すると、“ｋ＋１”ユニットの垂直型エンジンだけが必要とされる。ここで、ｋ＝（ｊ＋３）／４の整数である。ビデオコーディングアーキテクチャを設計する際に、電力消費と、シリコンエリアとは、変換エンジンの性能に対する重要なトレードオフ要因である。]
[0050] 図５は、ここで記述するような変換とともにパイプライン化技術に対して、計算再使用技術を使用してもよいアーキテクチャを図示するブロック図である。図５に示したアーキテクチャ例を使用して、ＦＴＥ５２Ｂを実現してもよい。ここで、４つの水平型エンジンが使用され（ｊ＝３）、したがって、この設計アーキテクチャ中で効率的なデータ共有を持つために、２つの垂直型エンジンが使用されてもよい（ｋ＝２）。図５に示したように、ＦＴＥ６０は、ランダムアクセスメモリ（ＲＡＭ）６２、２つの垂直型エンジン（ＶＥ（０）６４Ａ、および、ＶＥ（１）６４Ｂ）、２つの転置メモリＴＭ６５Ａ、およびＴＭ６５Ｂ、ならびに、４つの水平型エンジン（ＨＥ（０）６６Ａ、ＨＥ（１）６６Ｂ、ＨＥ（２）６６Ｃ、および、ＨＥ（３）６６Ｄ）を含む。] 図５
[0051] ＦＴＥ６０は、垂直および水平方向の両方で、４×４フォワード変換を実現してもよい。一般的に、垂直変換、または、水平変換のいずれが最初に実行されるかどうかは、問題にならない。言い換えると、変換のシーケンス（垂直および水平）は、他の実現において交換することができる。したがって、他の実現において、水平変換は、垂直変換の前に実行されてもよい。図５において、垂直変換は、水平変換によって後続される第１の変換動作である。] 図５
[0052] 図５に示したように、アーキテクチャは、４つの水平型エンジン６６Ａ−６６Ｄと、２つの垂直型エンジン６４Ａ−６４Ｂの使用を行う。ＲＡＭ６２は、垂直型エンジン６４Ａ−６４Ｂに供給されるサーチ空間ピクセルを含んでもよい。垂直型エンジン６４Ａ−６４Ｂは、転置メモリ６５Ａ−６５Ｂに接続されており、転置メモリ６５Ａ−６５Ｂは、水平型エンジン６６Ａ−６６Ｄに対してデータを供給する。水平型エンジン６６Ａ−６６Ｄは、１Ｄシストリックアレイの形態で、構成されることができる。以下により詳細に記述するように、いくつかの例において、水平型および垂直型エンジンは、４×４変換に基づいて設計されてもよい。しかしながら、変換サイズは任意のサイズ（例えば、Ｎ×Ｎ）であることができ、異なるサイズの変換は、中間計算の再使用に関係する利点を実現しつつ、ハードウェアエンジン設計を変更できる。] 図５
[0053] 上に述べたように、ここで記述した技術は、実行される１Ｄ変換の数に関して、最大３７．５％の削減を達成できる。しかしながら、図５に示したアーキテクチャは、２５パーセントの削減を達成してもよい。水平型エンジンの数が増加するにつれて、より多くの共有が発生されるので、計算削減の量を改善できる。１６個の水平型エンジンを維持するのに、５個の垂直型エンジンが必要とされるかもしれない。このケースでは、計算削減の量は、１−［（５＋１６）／（１６＋１６）］＝３４．４％になってもよい。一般的に、Ｎ個の水平型エンジンに対して、１＋Ｃｅｉｌ（（Ｎ−１）／４）の垂直型エンジンが必要とされてもよい。Ｃｅｉｌ（ ）は、正の無限（＋∞）に丸める。計算削減に対する一般化された数式は、以下のように与えられる。すなわち：
１−［（垂直型エンジンの数＋水平型エンジンの数）／（水平型エンジンの数＋水平型エンジンの数）］。] 図５
[0054] 図６は、本開示にしたがって、達成されてもよい計算的な節約を図示するグラフである。特に、図６は、（ｘ軸上の）並列にサーチされているポイントの数に基づいて、（ｙ軸上の）達成されることができる計算的な節約のパーセンテージをグラフ化する。一般的に、サーチポイントの数は、（垂直変換が最初に実行され、次に、水平変換が実行されることを仮定して、）水平型エンジンの数に等しくてもよい。例として、１６個の水平エンジンは、１６個のサーチポイントをカバーすべきである。したがって、図６のｘ軸上の値１６において、これは、グラフ上の３４．４％の節約に対応する。] 図６
[0055] 図７は、並列でサーチされてもよいサーチポイントの数の関数としての変換エンジンの数を図示するグラフである。図７は、（ｘ軸上の）並列にサーチされてもよい異なる数のサーチポイントに対して、（ｙ軸上の）水平型エンジンの数と、（ｙ軸上の）垂直型エンジンの数と、（ｙ軸上の）水平型および垂直型エンジンの結合数とをグラフ化する。] 図７
[0056] 再び、ＦＴＥにおいて、複数の水平型エンジンを使用して、変換スループットとデータ共有を改善する。ＦＴＥエンジンが、効率的なデータ共有と、比較的小さいエリアにおける低電力消費とを、確実に容易にできるように、ＦＴＥの垂直型および水平型エンジンは、異なるふうに設計されている。特に、クロック電力を節約するために、エンジンのデータレジスタの大多数は、ピクセルクロックレートの２分の１、または４分の１においてクロックすることによって設計されてもよい。（以下の）表１、表２、および表３は、使用することができるクロッキングスキームを図示する。]
[0057] 図８は、例示的な（垂直型エンジンとも呼ばれる）垂直型変換エンジン８０を図示するブロック図である。垂直型エンジン８０は、さまざまなレジスタＲ０（８１Ａ）、 Ｒ１（８１Ｂ）、 Ｐ０(８１Ｃ)、 Ｐ１(８１Ｄ)、 Ｐ２ (８１Ｅ) およびＲｆ（８１Ｆ）と、マルチプレクサ８２Ａ、８２Ｂ、８２Ｃ、８２Ｄ、８２Ｅ、および８２Ｆと、加算器８５Ａ、および８５Ｂとを備える。垂直型エンジン８０は、（図５の）ＲＡＭ６２から直接ピクセルデータを受け取る。垂直型エンジン８０とともに技術が実現されてもよく、ここで、垂直型エンジン８０は、入力ピクセルデータを再シーケンス化し、内部データパスを再配置し、ブロードキャストされたピクセル入力データを指定されたレジスタにラッチする。] 図５ 図８
[0058] 表１は、サーチポイントｓ（０，０）と、サーチポイントｓ（１，０）の一部とに対する、垂直型エンジン８０の例示的なデータフローとタイミングを示し、その変換は、クロックサイクル１６において開始する。特に、表１は、連続的なクロックサイクルにわたって入力（Ｉ／Ｐ）が与えられたとして、異なるレジスタの内容を示す。出力（Ｏ／Ｐ）は、レジスタＲｆ（８１Ｆ）の内容に対応していてもよい。再び、“分けられた（divided down）”クロック信号を使用してもよく、このケースでは、垂直型エンジン８０に対して等しいクロッキングパワーが、クロックサイクル毎に３つのレジスタを取り扱う。]
[0059] 一般的に、サーチポイントｓ（ｉ，ｊ）に対して、ＲＡＭ６２からのピクセルデータは、以下のように再シーケンス化される。]
[0060] レジスタＲ０（８１Ａ）は、クロック２ｎサイクルにおいてイネーブルされて、ピクセルデータをラッチする。]
[0061] レジスタＲ１（８１Ｂ）は、２クロックサイクル毎に入力ピクセルデータをラッチする。レジスタＲ０（８１Ａ）クロックは、クロック２ｎ＋１サイクルにおいてイネーブルされて、ピクセルデータをラッチする。]
[0062] 中間変換データを保持するのに使用されるレジスタＰ０ ８１Ｃ、Ｐ１ ８１Ｄ、Ｐ２ ８１Ｅに対して、Ｐ０（８１Ｃ）クロックはサイクル４ｎ＋１においてイネーブルされてラッチし、]
[0063] サイクル４ｎ＋２における、Ｐ１（８１Ｄ）は、以下のようにラッチし、]
[0064] そして、サイクル４ｎ＋３における、Ｐ２（８１Ｅ）は、以下のようにラッチし、]
[0065] サイクル４ｎ＋４における、Ｐ２（８１Ｅ）は、以下のようにラッチする。]
[0066] レジスタＲｆ（８１Ｆ）は、最終変換結果を保持するのに使用され、クロックサイクル毎にイネーブルされる。サーチポイントｓ（ｉ，ｊ）に対して、垂直に変換された出力シーケンスは以下のようである。]
[0067] 表１において、フォース（forth）列中に図示された矩形波は、システムクロックを表す。垂直型エンジン８０中のすべてのデータはこのシステムクロックの立ち上がりエッジにおいてレジスタ登録される。]
[0068] 水平型エンジンが垂直に変換されたデータを効率的に共有できるように、
それは、４×４の垂直に変換されたデータをシーケンス的な順序で取らなければならず、有効なデータ共有を作用させるいくつかの異なる順序があり、ここで示した例は、これらのうちの１つだけのものである。電力消費を最小化させるために、水平型エンジンが、垂直に変換されたデータを即座に消費することが望ましい。転置レジスタＴＭ６５Ａ、６５Ｂは、垂直に変換されたデータを、一時的に記憶し、再シャッフルするように設計されている。図１２は、垂直型および水平型エンジンに対する入力および出力シーケンスを表す。図１３は、水平型エンジンに対する垂直に変換されたデータを再シーケンス化するのに要求される最小のＴＭレジスタを表す。] 図１２ 図１３
[0069] （図５のエンジン６６Ａ−６６Ｄのような）水平型エンジンにおける効率的な処理のために、メモリに対するアクセスを最小化させることが望ましい。さらに、データが破棄される前に、すべてのアクセスされたデータを処理させることが望ましい。効率的にこれらのゴールを達成するために、２つの異なるタイプの水平型エンジンＨＥ（０）９０と、ＨＥ（ｊ）１００とが使用されてもよい。ＨＥ（０）９０は、（図５の）水平型エンジン６６Ａに対応してもよく、ＨＥ（ｊ）１００は、エンジン６６Ｂ−６６Ｄのそれぞれに対応してもよい。] 図５
[0070] それぞれの水平型エンジンは、４ストリングのデータを取り、これらはデータシーケンス０、データシーケンス１、データシーケンス２、および、データシーケンス３である。これらのシーケンスは、以下のように示される。]
[0071] Ｓ’（ｉ，ｊ）は、垂直に変換されたピクセルデータを表す。水平型エンジンＨＥ（０）に対して、すべての４シーケンスデータは、垂直型エンジンＶＥ（０）からの入力である。]
[0072] 水平型エンジンＨＥ（ｊ）１００に対して、その入力データシーケンス０、およびシーケンス１は、ＨＥ（０）９０のレジスタ９１Ｂおよび９１Ｃからのものであり、シーケンス２データは、ＨＥ（０）９０の９２Ｈの共有データ出力からのものであり、ＨＥ（１）１００のシーケンス３データは、垂直型エンジンＶＥ（１）８０からの直接のものである。]
[0073] 水平型エンジンＨＥ（２）１００と、そのシーケンス０データ入力は、ＨＥ（０）９０レジスタ９１Ｃからのものであり、シーケンス１データは、ＨＥ（０）の共有データ出力９２Ｈからのものであり、シーケンス２データは、ＨＥ（１）１００の共有データ出力９２Ｈからのものであり、ＨＥ（２）のシーケンス３データは、垂直型エンジンＶＥ（１）８０からの直接のものである。]
[0074] 水平型エンジンＨＥ（ｊ）１００、ここでｊ≧３に対して、その入力データシーケンス０、シーケンス１、およびシーケンス２は、その隣接水平型エンジンＨＥ（ｊ−３）、ＨＥ（ｊ−２）、および、ＨＥ（ｊ−１）それぞれの共有データ出力マルチプレクサ１０２Ｈを使用する。ＨＥ（ｊ）のシーケンス３データは、いつも垂直型エンジンＶＥ（ｋ）出力から直接到来する。ここで、ｋ＝（ｊ＋３）／４の整数である。]
[0075] 以下の表２と表３は、水平型エンジンＨＥ（０）９０とＨＥ（１）１００の入力、出力、および内部制御タイミングを示す。Ｒ０（９１Ａ）、Ｒ１（９１Ｂ）、Ｒ２（９１Ｃ）、Ｒ３（９１Ｄ）、およびＲ０（１０１Ａ）は、４クロックサイクル毎に１回だけイネーブルされ、中間レジスタＰ０（９１Ｅ、１０１Ｂ）、Ｐ１（９１Ｆ、１０１Ｃ）は、２クロックサイクル毎にデータをラッチする。]
[0076] 図９は、例示的な（水平型エンジンＨＥ（０）としても呼ばれる）水平型変換エンジンＨＥ（０）９０を図示する。図１０は、例示的な水平型エンジンＨＥ（ｊ）１００を図示する。図９の水平型エンジン９０は、ラベル付けされた、さまざまなレジスタＲ０（９１Ａ）、Ｒ１（９１Ｂ）、Ｒ２（９１Ｃ）、Ｒ３（９１Ｄ）、Ｐ０（９１Ｅ）、Ｐ１（９１Ｆ）、およびＲｆ（９１Ｇ）と、マルチプレクサ９２Ａ、９２Ｂ、９２Ｃ、９２Ｄ、９２Ｅ、９２Ｆ、９２Ｇ、９２Ｈと、加算器９５Ａおよび９５Ｂとを含む。図１０の水平型エンジン１００は、ラベル付けされた、さまざまなレジスタＲ０（１０１Ａ）、Ｐ０（１０１Ｂ）、Ｐ１（１０１Ｃ）、およびＲｆ（１０１Ｄ）と、マルチプレクサ１０２Ａ、１０２Ｂ、１０２Ｃ、１０２Ｄ、１０２Ｅ、１０２Ｆ、１０２Ｇ、１０２Ｈ、および１０２Ｉと、加算器１０５Ａおよび１０５Ｂとを含む。図８、９、１０に示したレジスタは、それぞれのエンジンの物理的構造を備えていてもよいが、記憶構造は互いに類似していてもよい。言い換えると、図８中のレジスタＲ０（８１Ａ）は、図９中のレジスタＲ０（９１Ａ）とは異なる。] 図１０ 図８ 図９
[0077] 水平型エンジンＨＥ（０）９０は、最初の４×４ピクセル列ブロック（Ｎ×Ｍサイズのサーチエリアからのサーチポイントｓ（０，０），ｓ（１，０）・・・ｓ（Ｍ−３，０））を変換するように設計されていてもよい。対照的に、（図１０に示された）水平型エンジンＨＥ（ｊ）１００を繰り返し使用して、列ブロックの残り（サーチポイントｓ（０，ｊ），ｓ（１，ｊ）・・・ｓ（Ｍ−３，ｊ）（１≦ｊ≦Ｎ−３））を変換してもよい。図９の水平型エンジンＨＥ（０）９０は、図５のＨＥ（０）６６Ａに対応していてもよく、図９の水平型エンジンＨＥ（ｊ）１００は、図５のＨＥ（１）６６Ｂ、ＨＥ（２）６６Ｃ、およびＨＥ（３）６６Ｄのそれぞれに対応していてもよい。] 図１０ 図５ 図９
[0078] 水平型エンジンＨＥ（０）９０は、（図５の）垂直型エンジンＶＥ（０）から４つの４分の１のピクセルクロックされたデータレジスタＲ０（９１Ａ）、Ｒ１（９１Ｂ）、Ｒ２（９１Ｃ）、Ｒ３（９１Ｄ）へとブロードキャストされたシーケンスのピクセルデータをラッチし、中間変換関数を実行し、次に、結果をレジスタＰ０（９１Ｅ）およびＰ１（９１Ｆ）に記憶する。レジスタＰ０（９１Ｅ）およびＰ１（９１Ｆ）は、第２のバタフライ演算に対するデータを記憶し、結果が最終レジスタＲｆ（９１Ｇ）に配信される。] 図５
[0079] 水平型エンジン９０のレジスタＲ０（９１Ａ）、Ｒ１（９１Ｂ）、Ｒ２（９１Ｃ）、およびＲ３（９１Ｄ）においてラッチされたデータは、次の３つの水平型エンジンＨＥ（１）、ＨＥ（２）、ＨＥ（３）によって共有されてもよい（図５の６６Ｂ−６６Ｄ参照のこと）。一般的に、水平型エンジンＨＥ（ｊ）１００（ここで、ｊ＝１，２，または３）のそれぞれに対して、入力データはＨＥ（０）出力、ＶＥ（１）出力、および、“前の”ＨＥ（ｊ）エンジンをマルチプレクスしたものから到来する。] 図５
[0080] 表２は、水平型エンジンＨＥ（０）−ＨＥ（３）の間でのタイミングと、どのようにデータが共有されるかとを示す。特に、表２は、サーチポイントｓ（０，０）、ｓ（１，０）、ｓ（２，０）・・・等で作用している、水平型エンジンＨＥ（０）６６Ａのタイミング情報を示す。サイクル０Ｓ’００において開始しているピクセルデータは、サーチポイントｓ（０，０）に関係する４×４ブロックの最初のピクセルである。サイクル１６Ｓ’１０において開始しているデータは、サーチポイントｓ（１，０）に対する４×４ブロックの最初のピクセルを指す、等。表２は、表２に提示したものに類似したタイミング関係を適用することによって、終了サーチポイントｓ（Ｍ−３，０）まで容易に延長することができる。]
[0081] 表３は、サーチポイントｓ（０，１）の４×４マッチングエリアに対するＨＥ（１）エンジンの１６ピクセルタイミングと、サイクル１７から開始するサーチポイントｓ（１，１）のピクセルタイミングの一部とを表示する。表３のデータシーケンス０、シーケンス１、およびシーケンス３は、水平型エンジンＨＥ（０）からのＲ１、Ｒ２、およびＲ３レジスタ値からのコピーであり、これは、水平型エンジンＨＥ（１）からＨＥ（３）の間で共有されている。表３において、ＨＥ（０）とＨＥ（１）との間のタイミング関係とデータフローを図示するために、レジスタ値を列挙した。留意すべきことに、“分けられた”ピクセルクロック周波数を使用することによって、等しいクロッキングパワーがより多くのレジスタを使用することによって達成される。例えば、ＨＥ（１）は、設計において、２．２５レジスタに等しいクロッキングパワーを有する４つの物理的レジスタを持っていてもよく、ＨＥ（０）は、３つのレジスタに等しいクロッキングパワーを有する７つのレジスタを持っていてもよい。]
[0082] 表４は、ＶＥ（０）、ＶＥ（１）、ＨＥ（０）、ＨＥ（１）、ＨＥ（２）、およびＨＥ（３）の間の例示的なタイミング関係を示す。特に表４は、垂直型および水平型エンジンＶＥ（ｋ）およびＨＥ（ｊ）（ここで、ｋ＝０，１であり、ｊ＝０，１，２，３である）の間での入力タイミング関係と、垂直変換されたデータが、水平型エンジンＨＥ（ｊ）の間で、どのように共有されるかとを図示する。表４は、サーチポイントｓ（ｉ，ｊ）に対するタイミング情報だけを提供し、ここで、ｉ＝０，１，２…４であり、ｊ＝０，１，・・・３である。すべての、サーチポイントｓ（ｉ，ｊ）に対する、類似のタイミングパターンが容易に開発されることができ、ここで、ｉ＝０，１，２…Ｍ−３であり、ｊ＝０，１，・・・Ｎ−３である。]
[0083] ＦＴＥ変換アーキテクチャは、エンジンによって決定されるだけでなく、垂直型および水平型エンジンの間のデータフローによっても決定される。アーキテクチャは、ピクセルレートパイプライン化された設計を備えているので、複数のエンジンの中間の何らかの歪んだデータフローは、パイプラインを機能停止させかねない。この問題を避けるために、複数のエンジンの中間で、転置メモリ６５Ａと６５Ｂをバッファ用に使用して、データのタイミングに対処してもよい。]
[0084] 本開示の技術は、パイプライン化された方法で、ビデオデータの１組のブロックに関して、変換が実行されるのを可能にする。特に垂直型エンジンおよび水平型エンジンは、（図５の）ＦＴＥ６０を通してデータがパイプライン化されるように、少なくとも一部の変換に対して同時に動作してもよい。例えば、図５に示したように、垂直型エンジン６４Ａおよび６４Ｂによって、データを処理して、転置メモリ６５Ａと６５Ｂ中に出力を記憶させることができる。第１のビデオブロックに関係するすべての垂直データが処理された際に、垂直型エンジン６４Ａおよび６４Ｂは、（適切なように中間結果を再使用しながら）第２のビデオブロックに関係する垂直データを処理してもよい。転置メモリ６５Ａと６５Ｂは、このようなデータが水平型エンジン６６Ａ−６６Ｄのうちの１つによって処理されるまで、必要とされる間じゅう、垂直型エンジン６４Ａおよび６４Ｂの出力を記憶することを可能にする。このような方法で、ＦＴＥ６０を通してデータがパイプライン化される。] 図５
[0085] 一般的に、垂直型エンジン６４Ａまたは６４Ｂのうちの１つによるデータ発生と、水平型エンジン６６Ａ−６６Ｄのうちの１つによる消費の間のタイミング歪みの最大量は、要求される転置メモリ（ＴＭ）の最小量を規定する。移行の間に、最も小さいＴＭを持つために、一般的に以下のようにすることが望ましい：
１．フィーダーエンジン（発生器）と、レセプター（消費する）エンジンとの間のデータタイミング歪みを最小化させること。]
[0086] ２．発生されたフィーダーエンジンデータを可能な限り早く消費すること。]
[0087] ＴＭを実現する１つの方法は、ランダムアクセスメモリ（ＲＡＭ）を使用することである。ＲＡＭベースの設計の欠点は、以下のようである：
１．ＲＡＭのアドレスサイズ（タイミング歪みに等しく、１６クロックサイクルよりも少ない）が小さく、ＲＡＭの形状が物理的設計において効率的でないかもしれない。留意すべきことに、２つの４×４変換の間の、最大のタイミング歪みは、１５クロックサイクルであってもよい。]
[0088] ２．各４×４変換の１６クロックサイクルの間に、メモリは、同じクロックサイクルの間に複数回、読み出され、また、書き込まれることができる。このことは、２ポートＲＡＭが使用されない限り、ＲＡＭがピクセルクロックレートの２倍運転しなければならないことを意味する。]
[0089] ３．より小さいＲＡＭベースの設計に対して、メモリテスト論理は、そのエリアアドバンテージをオフセットする。]
[0090] これらの要因を仮定して、シリコン上の物理的実現が困難性を経験しないときに、垂直型および水平型エンジンの間での転置メモリとしてのＲＡＭの使用を考慮することができる。]
[0091] 別のＴＭ設計アプローチは、レジスタベースの設計である。転置メモリまたは転置レジスタのいずれが使用されるかに関わらず、同じパイプライン化技術が使用されてもよい。図１１は、どのように入力ブロックがサーチ空間中で規定されてもよいかを図示する。図１２は、垂直型および水平型エンジンの間の入出力データフローを図示する。垂直型エンジン入力データと、水平型エンジン入力データに関連する垂直型エンジン出力データとの再順序付けを容易にするために、図１２に示した方法で、インデックスを追跡することは、変換プロセスの効率性を改善する。ｓ００，ｓ３０，ｓ１０，ｓ２０・・・ｓ０１，・・・ｓ２３シーケンスにおけるピクセル入力を有する垂直型エンジン設計は、最も少ないコンポーネントを使用してもよい。このケースでは、ＶＥ変換出力は、Ｓ’００，Ｓ’２０，Ｓ’１０，Ｓ’３０・・・Ｓ’３３フォーマットにしたがう。このことは、入力垂直型エンジンデータの出力垂直型エンジンデータに対する再順序付けを追跡するように、インデックスから配列（array）へと追跡することによって、純粋に論理的方法で行われてもよい。インデックスを追跡することは、メモリを更新することなく、データが１つのロケーションに記憶されることを可能にし、不必要な書き込み動作をなくす。当業者はまた、データをメモリ中に再度書き込みすることによる再順序付けも行われてもよいことを理解するだろう。] 図１１ 図１２
[0092] 入力データを共有するために、水平型エンジン入力が、シーケンス化されたフォーマットであることが望ましい。このケースでは、パイプライン化技術を使用してもよく、これによって、垂直型および水平型エンジンが、ビデオデータのパイプラインに関して並列で作用する。効率的なパイプライン化されたデータ処理のために、水平型エンジンは、垂直型エンジンによって発生された第１のデータが利用可能になるとすぐに、この第１のデータを入力してもよい。したがって、水平入力は、Ｓ’００，Ｓ’０１，Ｓ’０２，Ｓ’０３・・・Ｓ’３３シーケンスフォーマットにおけるものであってもよい。図１２の垂直型エンジン出力シーケンス（ＶＥＲ． Ｏ／Ｐ ＳＥＱ．）と、水平型エンジン入力シーケンス（ＨＯＲ．Ｉ／Ｐ ＳＥＱ．）とを比較すると、最大の対応する差異は、１３−４＝９であり、これは、このケースにおいて、９つの転置レジスタが必要とされることを示す。当業者は、より大きいブロックサイズが、異なる数の転置レジスタを要求してもよいことを理解するだろう。数は、データが処理のために利用可能になる最早の時間に関連する。転置レジスタの適切な数を選択することによって、過剰のレジスタを回避するように、パイプライン化を効率的な方法でサポートすることができる。このケースでは、可能な限りすばやくデータ処理パイプラインにおいてこのようなデータが使用されることを可能にする十分な時間の間にすべての必要なデータを保存するために、追加の、または超過量のメモリまたはレジスタを必要とすることなく、９つの転置レジスタで十分であってもよい。] 図１２
[0093] 図１３は、垂直型および水平型エンジンの間で使用されてもよい転置レジスタ（ＴＲ）の数を示す。図１３の左側の番号は、時間マークである。したがって、この例において、時間Ｔ１において、垂直型エンジンはＳ’００を出力し、Ｔ２において、垂直型エンジンは、Ｓ’２０を出力する・・・等。図１３において斜線を引かれたエリアは、出力が水平型（レセプター）エンジンによって消費される前に、どれくらいの間、垂直型エンジン（フィーダー）出力が、ＴＲ中に記憶されるかを表す。ここで、水平型エンジンは、垂直型エンジンの出力の消費を時間Ｔ１０から開始して、時間Ｔ２５において終了する。図１３の右側の数は、それぞれの時間マークにおいて、必要とされるＴＲの数を表し、これは斜線のエリアの合計量に等しい。図１３によって推定された合計ＴＲもまた９である。時間１３におけるピクセル番号は、ＴＲへとラッチされることなく、水平型エンジンに直接供給される。] 図１３
[0094] いくつかの技術と例を記述してきた。記述した技術を、ハードウェア、ソフトウェア、ファームウェア、または、これらの任意の組み合わせで実現してもよい。ソフトウェアにおいて実現される場合、ここで記述した技術は、デバイス中で実行される際に、上に記述した１つ以上の技術を実行させる命令を備えるコンピュータ読取可能媒体中で実現されてもよい。例えば、命令は、実行される際に、ビデオコーディングデバイスが、ビデオデータのブロック上に変換を実行することをもたらしてもよく、ここで、変換を実行することは、ビデオデータの第１のブロックの第１の変換に関係する計算を、ビデオデータの第２のブロックの第２の変換において再使用することを含む。]
[0095] コンピュータ読取可能媒体は、同期ダイナミックランダムアクセスメモリ（ＳＤＲＡＭ）のようなランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、電子的消去可能プログラム可能読出専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ（登録商標）、磁気または光学データ記憶媒体、および類似物を含んでもよい。命令は、１つ以上のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、１つ以上の特定用途向け集積回路（ＡＳＩＣ）、１つ以上のフィールドプログラム可能ゲートアレイ（ＦＰＧＡ）、あるいは、同等な集積または個別の論理回路のような１つ以上のプロセッサにおいて実行されてもよい。いくつかの実施形態では、ここで記述した機能は、オーディオマルチメディア情報をエンコーディングおよびデコーディングするように構成されている、専用ソフトウェアモジュールまたはハードウェアユニット内で提供されてもよく、結合マルチメディアエンコーダデコーダ（ＣＯＤＥＣ）に組み込まれてもよい。]
[0096] ハードウェアで実現される場合、本開示の技術は、ビデオデータのブロックへの変換を実行するように構成された回路に向けられていてもよく、ここで、変換を実行する際に回路は、ビデオデータの第１のブロックの第１の変換に関係する１つ以上の計算を、ビデオデータの第２のブロックの第２の変換において再使用する。例えば、回路は、集積回路、または、チップセットを形成する１組の回路を含んでいてもよい。回路は、ＡＳＩＣ、ＦＰＧＡ、さまざまな論理回路、集積回路、または、これらの組み合わせを含んでもよい。]
[0097] 本発明のさまざまな観点を説明した。これらの、および、他の観点は、以下の特許請求の範囲内のものである。]

权利要求:

請求項1
ビデオデータのブロック上で変換を実行するビデオコーダを具備するデバイスにおいて、前記ビデオコーダは、前記変換を実行する際に、ビデオデータの第１のブロックの第１の変換に関係する１つ以上の計算を、ビデオデータの第２のブロックの第２の変換において再使用するデバイス。
請求項2
前記ビデオコーダは、整数変換と離散コサイン変換（ＤＣＴ）とからなるグループからの変換を実行する、請求項１記載のデバイス。
請求項3
前記ビデオコーダは、動き推定器を備え、前記動き推定器は、前記変換を実行する変換エンジンを含む、請求項１記載のデバイス。
請求項4
前記ビデオデータの第１のブロックと、前記ビデオデータの第２のブロックとは、サーチ空間に関係するビデオデータを含み、前記変換エンジンはまた、エンコードされることになるビデオデータのブロック上で変換を実行する、請求項３記載のデバイス。
請求項5
前記ビデオコーダは、前記サーチ空間内で規定されているビデオデータの４つ以上のブロック上で変換を実行し、前記ビデオコーダは、前記サーチ空間内で規定されている前記ビデオデータのブロックのうちの少なくとも３つの変換において、計算を再使用する、請求項１記載のデバイス。
請求項6
前記ビデオデータのブロックは、４×４ピクセルブロックを含み、前記変換は、中間結果を発生させるための、前記４×４ピクセルブロックの行上での１次元変換と、前記中間結果の列上での１次元変換とを含み、前記再使用される計算は、前記中間結果のうちの少なくともいくつかを含む、請求項１記載のデバイス。
請求項7
前記ビデオコーダは、前記変換を実行する、１つ以上の水平型エンジンと、１つ以上の垂直型エンジンとを備える、請求項６記載のデバイス。
請求項8
前記ビデオコーダは、前記１つ以上の水平型エンジンと、前記１つ以上の垂直型エンジンとの間に、１つ以上の転置メモリをさらに備え、前記１つ以上の転置メモリは、前記エンジンのうちの１つからの出力データをバッファし、前記エンジンのうちの１つに対する入力データに対する、前記エンジンのうちの１つからの出力データのタイミングに対処する、請求項７記載のデバイス。
請求項9
前記変換は、パイプライン化された方法で、ビデオデータの１組のブロックに関して実行され、前記水平型エンジンと、前記垂直型エンジンとは、前記変換の少なくとも一部に対して同時に動作する、請求項８記載のデバイス。
請求項10
前記ビデオコーダは、前記出力データに対する前記入力データに関係するインデックス値を追跡し、前記インデックス値によって、前記出力データに対する前記入力データを再順序付けする、請求項８記載のデバイス。
請求項11
前記ビデオコーダは、前記１つ以上の水平型エンジンと、前記１つ以上の垂直型エンジンとの間に、１組の転置レジスタをさらに備え、前記１組の転置レジスタは、前記エンジンのうちの１つからの出力データをバッファし、前記エンジンのうちの１つに対する入力データに対する、前記エンジンのうちの１つからの出力データのタイミングに対処する、請求項７記載のデバイス。
請求項12
前記変換は、パイプライン化された方法で、ビデオデータの１組のブロックに関して実行され、前記水平型エンジンと、前記垂直型エンジンとは、前記変換の少なくとも一部に対して同時に動作する、請求項１１記載のデバイス。
請求項13
前記ビデオコーダは、前記出力データに対する前記入力データに関係するインデックス値を追跡し、前記インデックス値によって、前記出力データに対する前記入力データを再順序付けする、請求項１１記載のデバイス。
請求項14
前記デバイスは、ワイヤレス通信デバイスを含む、請求項１記載のデバイス。
請求項15
前記デバイスは、高精細度テレビジョン（ＨＤＴＶ）を含む、請求項１記載のデバイス。
請求項16
前記ビデオデータのブロックは、４×４ピクセルブロックを含み、前記変換は、中間結果を発生させるための、前記４×４ピクセルブロックの列上での１次元変換と、前記中間結果の行上での１次元変換とを含み、前記再使用される計算は、前記中間結果のうちの少なくともいくつかを含む、請求項１記載のデバイス。
請求項17
ビデオデータのブロック上で変換を実行する方法において、前記変換を実行することは、ビデオデータの第１のブロックの第１の変換に関係する１つ以上の計算を、ビデオデータの第２のブロックの第２の変換において再使用することを含む方法。
請求項18
前記ビデオデータのブロックは、４×４ピクセルブロックを含み、前記変換は、中間結果を発生させるための、前記４×４ピクセルブロックの行上での１次元変換と、前記中間結果の列上での１次元変換とを含み、前記再使用される計算は、前記中間結果のうちの少なくともいくつかを含む、請求項１７記載の方法。
請求項19
前記ビデオデータのブロックは、４×４ピクセルブロックを含み、前記変換は、中間結果を発生させるための、前記４×４ピクセルブロックの列上での１次元変換と、前記中間結果の行上での１次元変換とを含み、前記再使用される計算は、前記中間結果のうちの少なくともいくつかを含む、請求項１７記載の方法。
請求項20
デバイスにおいて、ビデオデータのブロック上で変換を実行する手段と、ビデオデータの第１のブロックの第１の変換に関係する１つ以上の計算を、ビデオデータの第２のブロックの第２の変換において再使用する手段とを具備するデバイス。
請求項21
前記ビデオデータのブロックは、４×４ピクセルブロックを含み、前記変換は、中間結果を発生させるための、前記４×４ピクセルブロックの行上での１次元変換と、前記中間結果の列上での１次元変換とを含み、前記再使用される計算は、前記中間結果のうちの少なくともいくつかを含む、請求項２０記載のデバイス。
請求項22
命令を備えるコンピュータ読取可能媒体において、前記命令は、ビデオコーディングデバイス中で実行されるときに、前記デバイスに、ビデオデータのブロック上で変換を実行させ、前記命令は、前記変換を実行させる際に、前記デバイスに、ビデオデータの第１のブロックの第１の変換に関係する１つ以上の計算を、ビデオデータの第２のブロックの第２の変換において再使用させる、コンピュータ読取可能媒体。
請求項23
前記ビデオデータのブロックは、４×４ピクセルブロックを含み、前記変換は、中間結果を発生させるための、前記４×４ピクセルブロックの行上での１次元変換と、前記中間結果の列上での１次元変換とを含み、前記再使用される計算は、前記中間結果のうちの少なくともいくつかを含む、請求項２２記載のコンピュータ読取可能媒体。
請求項24
ビデオデータのブロック上で変換を実行するように構成されている回路において、前記変換を実行する際に、前記回路は、ビデオデータの第１のブロックの第１の変換に関係する１つ以上の計算を、ビデオデータの第２のブロックの第２の変換において再使用する回路。
請求項25
前記ビデオデータのブロックは、４×４ピクセルブロックを含み、前記変換は、中間結果を発生させるための、前記４×４ピクセルブロックの行上での１次元変換と、前記中間結果の列上での１次元変換とを含み、前記再使用される計算は、前記中間結果のうちの少なくともいくつかを含む、請求項２４記載の回路。